animateGridRowOut() relies on animationend to start cleanup/removal. If the animation doesn’t run (e.g., reduced-motion settings, missing/blocked CSS due to CSP, or other style overrides), animationend may never fire and the row (and any dependent cleanup callback) will be stuck. Add a fallback (e.g., timeout, or detecting prefers-reduced-motion and skipping straight to the collapse/removal) so rows are always removed and onComplete is guaranteed to run.

The new tests assert template output strings, but the dynamic row feature’s most failure-prone cases aren’t covered (e.g., controlling field defined after the grid field, and controlling field values provided via prepopulated data / old input that should affect the initial row count). Adding coverage for at least one of these scenarios would help prevent regressions in the JS initialization/watch behavior.

When setGridRowCount() reduces the number of rows, it deletes state and removes DOM nodes but it never dispatches the grid-row-removed event (used by the parent formHandler to drop/shift validation errors). This can leave stale error entries for removed rows, causing error summaries/scrolling to reference non-existent fields. Consider dispatching grid-row-removed for each removed index (or adding a dedicated event to clear errors for indices >= new count).

Inline <style> in the grid field template will be emitted once per grid instance, which can bloat HTML output and can break sites with strict CSP (no inline styles). Consider moving these keyframes/class rules into the package CSS (e.g., the compiled easy-forms.css) and only toggling classes from JS in the template.

Dynamic grid initialization reads the controlling field value from the partially-built acc object. This makes rowCount dependent on field order: if the grid field appears before the controlling field in the blueprint, acc[field.dynamic_rows_field] will be undefined and the grid will initialize with the wrong number of rows. A more robust approach is a two-pass initialization (initialize non-grid fields first, then grids) or to resolve the controlling field’s default from fields instead of acc.

initDynamicGridRows() registers a watcher but never applies the current controlling field value immediately. If the controlling field is prepopulated (or already set) before this watcher is registered, the callback won’t run and the grid can render with an out-of-sync row count until the user changes the control field. Call setGridRowCount(handle, this.submitFields[controlFieldHandle]) once during initialization (in addition to the watcher) to ensure correct initial state.

initializeFields() computes dynamic grid row count by calling fields.find(...) inside the reduce() loop. That makes initialization O(n^2) in the number of fields, which can become noticeable for larger forms. Consider precomputing a handle→field map (or handle→default map) once before the reduce and doing O(1) lookups instead.

Row enter/exit animations don’t fully respect prefers-reduced-motion: animateGridRowOut() skips animation when reduced motion is enabled, but the CSS-driven .ef-row-enter animation will still run. Consider adding a @media (prefers-reduced-motion: reduce) override to disable both .ef-row-enter/.ef-row-exit animations (and any transitions) for users who request reduced motion.

This change removes support for the grid_rows tag parameter (previously used to override grid row counts at render time). If this tag parameter is part of the public API, this is a breaking change for existing templates. Consider adding a deprecation path (or at least documenting the removal / migration to dynamic_rows_field / fixed_rows).